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Remarks 

This is a Response to the Official Action dated December 15, 2003. A petition for 
a one-month extension of time is included with this response. 

This response adds new claims 34 and 35. The new claims are used to broaden the 
scope of the invention and are not offered in response to the Examiner's rejections. The 
support for the new claims can be found on page 2, lines 19-28 of the specification. 

35 U.S.C, S103(a) Rejection 

Claims 1-5, 7-14, 21-24, 29-31 and 33 were rejected under 35 U.S.C. §103(a) as 
being unpatentable over "A Framework for Inter-ORB Request Level Bridge 
Construction" (herein after Steinder) in view of Nessett (U.S. Patent No. 5,742,759). 
Claims 15-20 and 32 were rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Steinder and Nessett in view of "ORB 2.0 RFP Submission" (herein after lONA). Claims 
25-28 were rejected under 35 U.S.C. §103 (a) as being unpatentable over Steinder and 
Nessett in view of Luckenbaugh (U.S. Patent No. 5,991,877). 

The Applicant submits that the Examiner has not established a prima facie case of 
obviousness for the claims rejected under 35 U.S.C. § 103(a). The Applicant notes: 

"To establish a prima facie case of obviousness, three basic criteria must 
be met. First, there must be some suggestion or motivation, either in 
the references themselves or in the knowledge generally available to one 
of ordinary skill in the art, to modify the reference or to combine reference 
teachings. Second, there must be a reasonable expectation of success. 
Finally, the prior art reference (or references when combined) must 
teach or suggest all the claim limitations. The teaching or suggestion to 
make the claimed combination and the reasonable expectation of success 
must both be found in the prior art, not in applicant's disclosure" 
(emphases added) In re VaecK 947 F.2d 488, 20 USPQ2d 1438 (Fed. Cir. 
1991). 

The Applicant submits that a prima facie case of obviousness has not been established for 
the reasons set forth below. 
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Claim 1 

A. The Applicant submits that Steinder fails to disclose, suggest or teach, inter alia, 
the following features recited by Claim 1 of the present application: 

"... the message including an identifier for a further object in either the 
first or second network . . . means to form a new identifier ..." (emphases 
added) 

Before addressing the Examiner's rejections, the Applicant submits that Steinder 
teaches the following. Steinder "addresses a problem of building a bridge between 
different CORBA compliant systems", page 1, lines 1-2 of Steinder. According to 
Steinder "CORBA 1 standard left some parts of the system undefined because the then 
state of the art did not allow standardization or some of the elements were intentionally 
left opaque to allow their specialization for different uses. These deficiencies in the 
CORBA definition allow vendors of CORBA compliant systems to specify different 
extensions to the same interfaces to make them usable. [As a] . , . result[,] interface 
implementation of one ORB caimot be directly ported to the other ORB . . . [Therefore,] 
to allow two different ORBs to cooperate a mapping from one ORB to another and vice 
versa must be defined", page 6, section 4.3, lines 1-9 of Steinder. According to Steinder 
mapping can be performed using one of two methods, eager mapping or lazy mapping, 
page 9, section 5.4, line 8, Irrespective of the mapping methods used, the client located in 
ORBl may send out REQ(Refl) to server in 0RB2, see Figures 5 and 6 of Steinder. 
According to Steinder a half-bridge (HB) in ORBl will map the REQ(Refl) from 
ORBl's "proprietary form to an Interoperable Object Reference (lOR) [form]", page 9, 
section 5.4, lines 3-4 and Figures 5 and 6 of Steinder. Once the mapping is complete 
REQ(IORl) is transmitted to HB located in 0RB2. The HB located in 0RB2 proceeds to 
remap the received REQ(IORl) to "server's ORB proprietary form", page 10, third full 
paragraph, line 2 and Figures 5 and 6 of Steinder. After the remapping is complete the 
REQ(Ref2) is forwarded to the server located in 0RB2, see Figures 5 and 6 of Steinder. 

The Applicants submit that Steinder does not teach, disclose or suggest "the message 
including an identifier for a further object ..." and "means to generate further interface 
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means . . .". The Examiner appears to assert that an lOR reference maybe be a further 
object, page 2, last full paragraph of the Official Action. However, as noted above, lORl 
is simply a remapping of the REFl. The Examiner has not shown where Steinder 
discloses the generation of the interface means for lOR reference. Therefore, the 
Applicant submits that Steinder does not teach, disclose or suggest "means to generate 
further interface means". 



B. The Applicant further submits that Nessett teaches away from the following 
features recited by Claim 1 of the present application: 

"... means to form a new identifier for the further interface means, the 
new identifier including check data resulting from a hash operation for 
checking the validity of the or at least part of the new identifier; means to 
replace the received identifier with the new identifier in the message; 
and means to forward the message to the object in the second 
network" (emphases added) 

According to Nessett "[i]n client-server computing, typically there is a set of 
computers that can communicate with one another through a network connecting the 
computers. Some of these computers act as providers of services or functionality to other 
computers. The provider of a service or functionality is known as a 'server', and the 
consumer of the service or functionality is called a 'client'", column 1, lines 26-32 of 
Nessett. In the second embodiment, Nessett describes steps "for securely controlling 
access to system resources", column 7, lines 29-30 of Nessett. According to the second 
embodiment "the client object . . . sends a Create request to the spreadsheet server object 
. . . The spreadsheet server receives the request and creates the spreadsheet object . . . The 
spreadsheet server object then sends to the client object ... a spreadsheet object 
reference ... The spreadsheet object reference may be run through a cryptographic one- 
way hash function to produce a cryptographic checksum on the object reference data. 
The cryptographic checksum is also saved in or associated with the spreadsheet object 
reference. The spreadsheet object reference then has greater protection against forgery" 
(emphases added), column 7, lines 33-52 of Nesset. 
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The Examiner asserts that "an identifier" recited by Claim 1 is disclosed by 
Nessett as "object reference", see page 3, last paragraph, line 2 of the Office Action. The 
Examiner further asserts that "check data" of Claim 1 is disclosed by Nessett as 
"checksum", see page 3, last paragraph, line 3 of the Office Action. Based on Nessett, 
summarized above, the client sends a request to the server and the server sends the object 
reference with the checksum back to the client. The object reference v^ith the checksum 
is not being send by the client to the server. The Applicant submits that Nesset t does not 
teach, disclose or suggest "means to form a new identifier for the further interface means, 
the new identifier including check data resulting from a hash operation for checking the 
validity of the or at least part of the new identifier; means to replace the received 
identifier with the new identifier in the message; and means to forward the message to the 
object in the second network" as claimed in Claim 1. 

C. The Examiner also failed to demonstrate some reason, suggestion, or motivation 
from the prior art as a whole for the person of ordinary skill to have combined or 
modified the cited references. "There is no suggestion in either [prior art] ... as to how 
the features of the two devices could be combined so as to meet the structure claimed" Ex 
parte Re Qua, 56 USPQ 279 (C.C.P.A. 1942). "When the incentive to combine the 
teachings of the references is not readily apparent, it is the duty of the examiner to 
explain why combination of the reference teachings is proper. . . . Absent such reasons or 
incentives, the teachings of the references are not combinable" Ex parte Skinner, 2 
USPQ2d 1788 (B.P.A.L 1986). Steinder discloses mediation between different ORBs. 
Nessett on the other hand discloses access control for systems apparently using the same 
ORBs although in distributed context. As stated by the Federal Circuit: "[i]t is 
impermissible to use the claimed invention as an instruction manual or 'template' to 
piece together the teachings of the prior art so that the claimed invention is rendered 
obvious.", In re Fritch, 972 F.2d 1260. The Applicant submits that the only reason these 
references were cited was because the Examiner used the present claims as a roadmap. 
As stated by the Federal Circuit "[o]ne cannot use hindsight reconstruction to pick and 
choose among isolated disclosures in the prior art to depreciate the claimed invention". In 
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re Fritch, 972 F.2d 1260. Therefore, the Applicant respectfully submits that the rejection 
is improper and should be withdrawn. 

Hence, the Examiner failed to establish a prima fascia case of obviousness. 
Therefore, Claim 1 is patentable over Steinder and Nessett and should be allowed by the 
Examiner. Claims 2-5 and 7-32, at least based on their dependency on Claim 1, are also 
believed to patentable over Steinder and Nessett. 

Claim 33 

The Examiner states that "as claim 33, this is a method claim that corresponds to 
system 1 ; notes the rejection to claim 1 above, which also meets the method claim." The 
Applicant submits that Claim 33 is patentable over Steinder and Nessett and should 
'allowed by the Examiner for the same reasons as stated for Claim 1 . 

Patentability of new Claims 34 and 35 

The Applicant asserts that the references, either alone or in combination do not 
disclose that the further interface means corresponds to the further object and the 
further interface means is generated only v^hen or after the message including 
the identifier for the further object is received. 
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Conclusion 



In view of the above, reconsideration and allowance of the pending claims are 
respectfully solicited. 

The Commissioner is authorized to charge any additional fees which may be required or 
credit overpayment to deposit account no. 12-0415. In particular, if this response is not 
timely filed, then the Commissioner is authorized to treat this response as including a 
petition to extend the time period pursuant to 37 CFR 1.136 (a) requesting an extension 
of time of the number of months necessary to make this response timely filed and the 
petition fee due in connection therewith may be charged to deposit account no. 12-0415. 

I hereby certify that this correspondence is being 
deposited with the United States Post Office with 
sufficient postage as first class mail in an envelope 
addressed to Commissioner for Patents POB 1450, 
Alexandria, VA 223 13- 1450 on 

April 12, 2004 Respectfully submitted, 
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